HamCall (October 1991)/HamCall (Whitehall Publishing)(1991).bin/prgming/ada/asr012.sup

Text File | 1987-11-02 | 115KB | 2,032 lines

.RR--!----!----!----!----!----!----!----!----!----!----!-------------------!-R
.po 5
..po 1
.he                 ASR Newsletter, Issue 12 Supplement, Oct 87
.fo                                                              Page #
Ada (tm) Software Repository (ASR) Newsletter     Issue 12 Supplement, Oct 87
Richard Conn, Newsletter Editor                   Published by Echelon, Inc.

                               THIS SUPPLEMENT
            Theme: Ada Education, Software Engineering, and Reuse

     I. Ada Education and Training .................................  2
          A. Part 1 ........  2    D. Comments on Parts 1-3 ........  8
          B. Part 2 ........  4    E. Part 4 ....................... 14
          C. Part 3 ........  6    F. Comments on Parts 1-4 ........ 17

    II. The Human Element in Software Engineering .................. 19

   III. The DoD and Software Reuse ................................. 21
          A. Part 5 ................................................ 21
          B. Comments on Part 5 .................................... 23
-----------------------------------------------------------------------------
I  wish to thank the following people for sharing their insights and  opinions
on the Defense Data Network:

Drew Adams                         Mike Feldman
Laboratories de Marcoussis         Department of EE & CS
Centre de Recherche de la          The George Washington University
  Compagnie Generale
  d'Electricite                    Sam Harbaugh

Ed Berard                          Bob Munck
EVB Software Engineering, Inc.     The MITRE Corporation

Carsten Bormann                    Lt. Scott A. Norton, USN
Communications and Operating       Naval Postgraduate School
  Systems Research Group
Technical University of Berlin     Pat Rogers
                                   University of Houston at Clear Lake
Lawrence Crowl
Computer Science Department        Pete Schilling
University of Rochester            ALCOA Laboratories

Dennis Doubleday                   D. Schimisky
Department of Computer Science     Naval Air Development Center
University of Maryland
                                   Stanley Shebs
Dick Dunn                          University of Utah
NASA Ames Research Center
                                   Craig Wylie
                                   Department of Computing
                                   University of Lancaster, UK

                                        -- Richard Conn, Editor
                                           ASR Newsletter 12 Supplement
                           ---------------------
          NOTE:  Statements  made  in  this  supplement  should  generally  be
considered to be personal opinions of the individuals and not necessarily  the
opinions of the U.S. government or any specific company or organization.
.pa
==============================================================================
I. A. Ada Education and Training - Part 1
Date:  1 May 1987 04:12:44 PDT
Subject: Ada Education and Training - Part 1
From: Edward V. Berard <[e-mail]>

It has happened again. Some DoD contractor has contacted our company for  some
"Ada training," and has described a "recipe for disaster."  Let me fill you in
on the details:

     1. Apparently this contractor was awarded a contract even though there is
little  evidence to suggest that anyone working on the software has  any  real
Ada experience. (You know how this works - pick a scenario: a) the  contractor
added  the word "Ada" to the list of languages on the resumes at the  back  of
the  winning  (?) proposal; b) the contractor assured  the  naive  contracting
office that the technical staff would have "adequate Ada training" by the time
any  software  was  written; c) the contractor  used  resumes  of  "qualified"
individuals  who are too busy on other projects to be assigned to the  current
project,  so management thought that they could either hire someone  with  the
needed skills by the time the coding started, or provide some absolute minimum
of training to the people actually assigned to the project.)

     2.  Not realizing that Ada technology impacts the entire  software  life-
cycle  (including business practices), management has waited until the  coding
is  about to start to train their technical staff in what, to the  management,
is "just another programming language."

     3.  Not wanting to waste any money on "software foolishness" (after  all,
the      management     believes     that     it     is      the      hardware
engineering/mathematics/science  that  is  the "real  work"),  management  has
dictated that the "Ada education" will consist almost entirely of one week  of
classroom  instruction. Being somewhat generous, management has also  provided
some  "Booch books" and some "Alsys tapes" which the technical staff can  look
at,  on their own time. (I am not knocking the quality or usefulness of  these
products, just their misuse.)

     4. Since the only computer that has an Ada compiler on it is tied up with
useful work, the one week of training they wish us to provide is a "hands-off"
course. We may provide the students with some small "paper exercises," but  we
are  being encouraged to forego any labs so that we can "cram as much  of  the
language into the heads of the participants as possible."

     5.  The management is not open to any suggestions on how to  improve  the
quality  of the Ada training. It also happens that some other  well-known  Ada
experts have attempted to enlighten the management, but have been rebuffed.

The results of this project can be foretold quite easily.:

     -   The programmers will find the Ada language to be "large, complex  and
confusing." The code they produce will be "AdaTRAN" at best.  There will be  a
great  deal of time spent trying to understand that "dumb  reference  manual."
Ada books that emphasize syntax to the exclusion of software engineering  will
become  prized possessions. Especially valuable will be books  and  references
which treat Ada as "a superset of Pascal."

     -  The programmers will find that the Ada development system is confusing
to  use.  Since it is likely that the design will be in a  constant  state  of
revision, the specification parts of the Ada program units will change  fairly
often,  necessitating frequent re-compilation and relinking. As the amount  of
code  grows, the time spent re-compiling and relinking will quickly  reach  an
intolerable  level.  Frequent references will be made to the large  amount  of
object code produced, and its inefficient running speed. But after all,  isn't
that what one would expect from such a large language?

     -   The  programmers will find many features of the Ada  language  to  be
extremely  bothersome. There will be frequent complaints about strong  typing,
private  types (if they are used at all), the time for task rendezvouses,  and
those strange generic things.

     -   More  source  code will be produced than  for  a  comparable  project
written  in FORTRAN or Pascal. The detractors of Ada will gleefully  point  to
this as an expected result.

     -   The  project  will be late, overbudget, and  the  software  will  not
perform at anywhere near the original specifications. Looking for a scapegoat,
management  and the technical staff will grab the first inanimate object  they
can find (you guessed it -- Ada), and blame it for any shortcomings or project
failures.   The contracting office, being equally naive about Ada  technology,
will accept without question that Ada is the culprit.

There  will,  of  course, be many other problems, but let  us  now  focus  our
attention on the root causes.

The  Ada  language  was designed by first identifying a  number  of  desirable
software engineering features (e.g., data abstraction, information hiding, and
encapsulation),  and  then  incorporating these features  into  a  programming
language.  Since  a  good  number  of  these  concepts  are  foreign  to  most
programmers and managers, it comes as no surprise that the concepts are  often
abused, if they are used at all.

Many  advocates  of Ada technology have pushed the language, and  ignored  the
software  engineering.  Yes, there have been some people within the  DoD,  and
outside  of the DoD, who have stressed software engineering, but their  voices
have  been lost in the din. [Note the on-again, off-again funding for  STARS.]
Part  of  the  blame lies at the feet ofthe DoD  for  not  stressing  software
engineering strongly enough.

Within the Ada Joint Program Office (AJPO) is the Ada Software Engineering and
Education  and Training (ASEET) group. Hopefully, one of ASEET's goals  is  to
define minimal qualifications for an Ada software professional. This should be
in addition to definitions for course content in an industry targeted Ada  and
software  engineering training curriculum. Without any  guidance,  contractors
are  free  to train (or not train) their technical staffs in any  manner  they
choose.   Further,  contracting offices continue to have no idea  as  to  what
constitutes a qualified Ada professional.

Of  course,  I am not going to let the contractor's management off  the  hook.
Unfortunately,  they learned a long time ago that software quality was  little
more  than a buzzword. (Note: Much is known about software quality,  including
how  to measure it. Sadly, this technology seems to be largely ignored.)  They
seem  to get paid regardless of the "quality" of the software product.  Is  it
any  wonder  why  they  view  software  as  a  necessary  evil,  and  software
engineering  training as a useless luxury? So what if the software  fails,  so
long as the hardware holds up.

There  is  a  one-word definition for learning: change. The  hope  behind  Ada
technology  is  that  this change will be for the better.  Until  there  is  a
greater  recognition that Ada education and training is different, the  change
may not be what the proponents of the new technology have predicted.

                -- Ed Berard
                   [phone]

==============================================================================
I. B. Ada Education and Training - Part 2
Date:  1 May 1987 05:20:10 PDT
Subject: Ada Education and Training - Part 2
From: Edward V. Berard <[e-mail]>

Some years ago, when I began offering one of the first hands-on Ada courses, I
invited  some of the members of the Ada Joint Program Office (AJPO) to sit  in
on  the  course. Those that accepted my proposition gave me  some  interesting
feedback. It seem to the AJPO folks that my Ada courses were severely  lacking
in  software  engineering.  I  was puzzled. I  had  incorporated  sections  on
structured  programming  and coding style into my notes. What  more  did  they
want?

I  now  know  that my first attempt at an Ada course was little  more  than  a
glorified  Pascal seminar. I gave short coding examples for labs, and  treated
packages,  tasks,  and  generics  as "advanced  features."  There  was  little
discussion of abstraction, information hiding, and encapsulation. The  message
eventually  got through to me that a "syntax course" was a "no no,"  and  that
software engineering was much more than just structured programming.  However,
there was still a major problem.

As  you  know,  the  software community, as a whole,  is  initially  not  very
receptive to software engineering concepts. Managers and programmers alike are
obsessed with code. The sooner you can get down to coding the more comfortable
they  feel.  Software  engineering  is  mockingly  referred  to  as  "software
religion" by many. Management continually assures me that there may be time to
learn something other than coding "later."

Let  me  assure  you that it takes a great deal of  persuasion  ("singing  and
dancing,"  cajoling)  to get management and the technical  staff  to  consider
software  engineering  as an important part of Ada training.   Fortunately,  I
have two things going for me. First, most software professionals want to do  a
good  job.  If I can show them a way which will make their  software  products
better, and justify my reasoning, they will generally accept the idea. Second,
software types are extremely goal oriented. Given proper goals, they will work
hard to achieve them.

Unfortunately,  there  are  those Ada trainers who are not  as  persuasive  as
myself.  They  are easily bullied by their client's management  and  technical
staff  into  giving  syntax-only  courses.  Since  their  clients  are   often
blissfully ignorant of the impact of poor software engineering, especially  on
an  Ada  project,  the  clients  often  see  no  immediate  benefit  from  the
incorporation of software engineering technology into an Ada training course.

In a perfect world, software contractors would want to do everything in  their
power  to produce a quality product. Unfortunately, many DoD contractors  seem
to  be primarily driven by money and DoD regulations which must be adhered  to
to ensure the continued flow of money.  (Don't get me wrong. I am very much  a
capitalist.)  This  implies that one way to improve the current state  of  Ada
education  and training might be some gentle prodding by the DoD. Say, in  the
form  of some recommendations from the Ada Software Engineering and  Education
and Training (ASEET) group.

Two months ago, I received a message from Doug Bryan who, among other  things,
teaches  an  Ada  course at Stanford University. I think  you  will  find  his
message to be of general interest.

------------------- Message Follows ------------------------

I tried something new (and costly) with my Stanford class this year.   Usually
I teach

     abstraction -> misc. s/w eng -> OOD -> reuse -> the details of Ada

This  year I tried reversing it since "the powers above" wanted it to be  more
of a programming class and less of a Software Engineering class.  So, I taught

          the details of Ada -> abstraction -> OOD (OOx) -> reuse

I'm  now  grading  some of the final projects and realizing this  was  a  real
mistake.   Their code is terrible and it's my fault.  Their packages are  best
classified   as  "collections  of  stuff";   Private  types,  generic   formal
parameters,  and decent use of attributes are practically  non-existent;  most
every subprogram is a procedure, all parameters of which are mode in out;  ...
the list goes on and on.

It  was costly, but I have seen first hand empirical evidence of what the  Ada
community has been telling itself (and others) for years:

      Ada without a software engineering foundation is MIL-STD Pascal.

live and learn...

------------------ End of Message --------------------

                -- Ed Berard
                   [phone]

.pa
==============================================================================
I. C. Ada Education and Training - Part 3
Date:  3 May 1987 12:23:12 PDT
Subject: Ada Education and Training - Part 3
From: Edward V. Berard <[e-mail]>

Recently,  an instructor at one of the military academies told me how she  had
selected  a book for an introductory Ada class. She had rejected Booch's  book
(Software  Engineering With Ada) in favor of another text. It was not so  much
the text she had selected that bothered me, as it was her reason for rejecting
Booch's book. "Booch takes too long to get to any code.", she said, "I want to
see something like 'Hello World' real quick." [For those of you who have never
programmed in C, or, more precisely, read Kernighan and Ritchie's book on  the
C  programming  language,  the "Hello World" program is the  first  C  program
covered in many introductory C courses.]

Kernighan  and Ritchie (K&R) and Booch represent two very different  views  on
teaching  programming.  K&R  stresses the age old  thinking  which  says  that
students  of software must see, write, and execute code before  anything  else
will  be meaningful. Booch, on the other hand, stresses that  students  should
know  what they are doing before they attempt to write code. The K&R  approach
has its roots in software antiquity.

Programming  code is the "cocaine" of the software world. To many  programmers
and  managers  it  is  all that matters. While  software  is  being  designed,
managers  wait nervously and the programmers/coders wait impatiently. One  the
design document is finished, the "real work" can begin. With any luck the code
which  is  produced  may  closely resemble what is  described  in  the  design
documentation.

To  an outsider this infatuation with code seems strange. One hears from  many
sources  that  coding usually takes up only 10 to 15 percent of  the  software
life-cycle. Why then do we focus so much attention on the syntax and semantics
of the programming language? Several reasons come to mind:

     1)  Many  of those who are already programmers  and  instructors  believe
strongly  that,  only if one is intimately familiar with code, can  one  fully
understand the implications of any other part of the software life-cycle.

     2) Some in the Ada community feel that the software engineering  embodied
in  the Ada language will either be obvious to the neophytes or  that  through
constant  use of the Ada language, good software engineering concepts will  be
absorbed "via osmosis."

     3)  The  concept of "instant gratification" is very  much  entrenched  in
modern  software  production. Sitting at their terminals in their  offices  or
cubicles,  programmers  very  much  resemble  "rats  in  Skinner  boxes"   who
continually press a lever (the RETURN key) for constant reenforcement of their
behavior.  We  are  only now beginning to see tools which  will  allow  us  to
"execute a design."

     4)  Software people have little faith in those concepts that come  before
the coding phase. "How can anyone possibly describe something which is not yet
coded?",  they  reason. There is little emphasis on non-coding tasks  in  most
commonly available training.

It  seems  that  most people have not understood the intentions  of  the  U.S.
Department of Defense (DoD) regarding the Ada effort. It is better  engineered
software  that is desired, not merely "FORTRAN rewritten using the syntax  and
semantics  of the Ada language." Too much emphasis has been placed on  a  tool
(Ada) and not on the task (better software).

Learning  the  details  of the Ada language is at the "noise  level"  of  most
software  projects.  In  fact, only a very small part of  any  "Ada  education
effort"  needs  to focus on the language itself. Concepts  like  configuration
management,  software  design methodologies,  data  abstraction,  concurrency,
software testing, and project management must be an important part of any  Ada
training effort.

Of course, there are many problems which must be solved, for example:

     -  Contracting offices and project managers must recognize that the least
significant part of any Ada training effort is the learning of the syntax  and
semantics  of the language. Yes, it is important for programmers to learn  the
Ada  language,  but this is a trivial task compared to learning  about  modern
software engineering.

     -   Many  of those who "teach" the Ada language are unfamiliar  with  the
bulk  of  modern  software  engineering.  For  example,  most  may  only  have
familiarity with functional decomposition approaches to software  development.
Few can name any references on software quality assurance. A surprising number
cannot  cite  any  studies which correlate coding  style  with  debugging  and
testing efficiency.

     -   When  software  engineering  concepts  are  introduced  into  an  Ada
curriculum,  it is often introduced in a very "watered down" form. This is  so
that  those  least  prepared to develop quality software  can  maintain  their
positions -- managers *and* programmers.

     -   There  is still a widely-held belief that all that is  involved  with
transitioning  to  Ada  technology is a change  of  programming  language.  In
reality,  software development and maintenance practices will have to  change,
in-house  and  government software standards will be  impacted,  and  business
practices  will change.  [It is often those in the commercial sector who  pick
this  up more readily than those in the defense sector. Further,  those  doing
business applications using Ada technology more quickly see the impact of  Ada
technology than those doing scientific and engineering applications.]

I  would  recommend that those charged with procuring Ada  training,  and  who
determine the Ada qualifications of a potential contractor, beyond mere coding
ability.  We  must  recognize that probably the  greatest  effort  facing  the
advocates of Ada technology will be reformation of "code junkies."

                -- Ed Berard
                   [phone]

.pa
==============================================================================
I. D. Comments on Parts 1-3
Date:         Mon, 4 May 1987 09:48 EST
From:         mike feldman <[e-mail]>
Subject:      Ed Berard's postings on education

Nice going again, Ed.

A cynic's view of all this might be that some of these contractors (and  their
opposite  numbers in the DoD project offices) may - precisely - _want_ Ada  to
fail  so they can continue with business as usual or find a convenient  excuse
for a waiver.

You  might accuse me of coming from a self-serving position, which I  am,  but
I'm  still convinced that the "Ada community" is still going about this  in  a
short-term  fashion. Ada and modern software engineering will succeed  in  the
long  run if we make it pervasive in the education process, which means  -  in
the long run - pervasive in university/college computing education.

This means a number of things:

     1.  Get  the  computer science  and  computer  engineering  accreditation
bureaucracies   to  recognize  that  software  engineering  is  a   legitimate
discipline  for  undergraduates.  It's  no  coincidence  that  most   software
engineering  teaching  is done at the grad level - you don't have  to  satisfy
accreditation bean-counters because graduate programs aren't accredited,  only
undergrad (did you know that?).

     2. Get the recognized textbook authors and mainstream publishers to write
books  that  will fit university curricula, which will not  change  overnight.
_Very  few_  Ada-oriented books fit into the right undergrad  pigeonholes.   I
tried  to do that with my Data Structures book, which sneaks Ada and  software
engineering  into  a mainstream undergrad course - where  is  my  competition?
Booch's  new  components book is _wonderful_ but probably too  voluminous  and
overtly  Ada-oriented to work in undergraduate courses, although I would  love
to be proved wrong.

     3. The Ada compilers-and-tools industry is also taking the  let's-get-the
short-term-bucks approach. This is a well-known hobbyhorse of mine, so I won't
bore  you  with  it again - but until the schools can get  into  Ada  and  Ada
environments  without  going broke in the process, they'll stick to  good  ol'
Pascal or whatever (Modula-2 _is_ starting to catch fire, though: do you think
most  of the same software engineering can be done with packages but no  other
Ada  goodies?).The  quality  of PC and Mac tools for  Pascal  and  C  oriented
education  gets better every day. And students can buy it for $35-50  a  copy.
Where is the _software engineering_ education tool stuff? Where is Ada for the
Mac?   Does anyone seriously believe that a school will plunk down $10000  for
_one_  copy of AdaGraph,even if you buy into the Pamela culture?  Does  anyone
seriously  think a school will invest heavily in Alsys systems? We  have  _30_
AT's  in a lab. Shall we put Alsys on 30 machines, or spend the same money  to
buy  30  Macs  or PS2/50's? If you were the guy  making  a  recommendation  to
University managers (who are _really_ naive about software engineering),  what
would you recommend? This is not a hypothetical question: I am in in _exactly_
that position.

Ed, and all the rest of you on the net: I'm not asking you for a handout. I've
spent  the  last  five years building grassroots support for  Ada  in  my  own
school.  I got it, but boy was it hard work, and I am not sure I would  invest
the  effort again, because 5 years ago I thought industry would recognize  the
need to do this nationally, but boy have I been disillusioned!

Ada and modern software engineering have _tremendous_ potential, and not  just
in  the  military  community. I have spent five years  as  a  computer-science
professor  trying to realize some of this potential. Industry: a few of us  in
the schools out here are really workin' hard to help you out; anybody ready to
help _us_?

Michael Feldman, Professor
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC  20052
202-994-7593
[e-mail]
[e-mail]

---------------------------------------------------------------------------
Date: 13 May 87 07:45:04 GMT
From: hao!ico![e-mail]  (Dick Dunn)
Subject: Re: Ada Education and Training - Part 3

In  one part of a rather lengthy article, Edward Berard takes on  Kernighan  &
Ritchie's _The_C_Programming_Language_.  He was talking about an  introductory
text, so I'm not sure why he's picking on K&R, but he compares their book with
Booch:

> Kernighan and Ritchie (K&R) and Booch represent two very different
> views on teaching programming. K&R stresses the age old thinking which
> says that students of software must see, write, and execute code
> before anything else will be meaningful.

This  is nothing more than an unthinking cheap attack on K&R.  It  would  seem
that Mr. Berard believes that K&R intends to teach programming simply  because
he  thinks it ought to do so.  However, if one manages to read as far  as  the
fourth paragraph of the Preface, one finds:

   "This book is not an introductory programming manual; it assumes some
   familiarity with basic programming concepts..."

Perhaps this was overlooked--after all, the Preface of a book may not be  good
reading  (unless you want to know the purpose of the book:-), so let's have  a
look  at  the beginning of the "real" text.  If we read as far as  page  1  of
"Chapter 0" we find the following terms used without prior definition:

    programming language, operating system, text-processing, data-base,
    characters, character strings, addresses, storage allocation, heap,
    garbage collection, file-access methods, single-thread control
    flow, coroutines

I  cannot, in my wildest dreams, imagine a normal neophyte being able to  read
this section...; he won't even be able to parse some of the sentences.

It  is not the case that K&R present the "programming first,  thinking  later"
approach.  They have set out to provide a ready introduction and reference for
a  particular programming language, and have succeeded in doing so.  K&R  have
been  set  up.   "We  want  an introductory  text.   We  will  label  them  an
introductory  text.  Then we will demonstrate that they have  failed."   [Hey,
look, the shop manual for my car doesn't provide spiritual guidance either.]

A somewhat worse confusion over teaching "programming" (I would rather a  less
loaded  term  implying  "the  complete  process  of  constructing  functioning
software") immediately follows in Berard's article:

>...Booch, on the other hand,
> stresses that students should know what they are doing before they
> attempt to write code...

The  reality  of  teaching  lies in  between  the  code-first  approach  (mis-
attributed  to K&R, but it does exist elsewhere) and an approach  which  holds
off the code until the concepts are ingrained...because the fact of the matter
is  that  very few students can hang on to a  substantial  abstract  framework
without something concrete to which they can relate it.

This  is  easy to observe in engineering and  physical  science  undergraduate
curricula.   In  the  first  year the students will be  taking  (let  us  say)
calculus  and some substantial classical physics which requires calculus.   If
the  calculus courses follow a purely mathematical development  of  functions,
series,  limits, etc. without adequate illustration of the application of  the
concepts, the math instructors find that their students are learning  calculus
better--and faster--in their physics courses.

(There  are, of course, areas where it's hard to find the concrete  material--
for example, some concepts in topology--but the production of software is  not
such an area.)

I'm not going to argue that the coding should come first.  That's not what I'm
saying  and it's not even in the back of my mind.  It would be silly to  teach
that  way...but  it's equally silly to think that you can (let  alone  should)
teach  the  concepts first and the programming later.  That's as  absurd  (and
antiquated)  as the "waterfall model" of software lifecycle.  Consider  it  an
overreaction to the "code first" approach.

It's all too simple:  Teach the two together.  Start developing the idea of  a
programming  language and a programming environment as you develop  the  first
concepts.   By the time you've got enough concepts to think about  interesting
problems,  you've also got enough concrete information to show what an  actual
solution to a simple problem might look like.  And, I know it's heresy in this
group where so many people think that there is One True Language, but you  can
use  a  couple of different programming languages to  illustrate  examples--if
you're careful, that can prevent students getting hung up on one language.

(This is somewhat how I was first taught.  Perhaps the two languages were  not
the  best choices--FORTRAN and BASIC--but hey, that was twenty-odd years  ago,
and it worked then.)

Another  way to look at what I'm saying:  overemphasizing the coding  is  bad;
ignoring it is just as bad.  A little more from Berard's article:

> Programming code is the "cocaine" of the software world. To many
> programmers and managers it is all that matters...

Replace  "cocaine" with "currency".  To many clients in the commercial  world,
the  code  is [almost!] all that matters, because they  aren't  interested  in
plans and studies except insofar as they help produce the end result, and they
don't believe that they can sell specs-by-the-pound.

The methodology is not the end product.

>...While software is
> being designed, managers wait nervously and the programmers/coders
> wait impatiently...

So get some good managers!  Sheeeesh!  As for the programmers/coders:  If  you
divide your world into "those who design" and "those who implement the design"
you  have  created a caste system.  You have a social problem and  you  cannot
solve it by waving methodology about.

>...To an outsider this infatuation with code seems strange. One hears
> from many sources that coding usually takes up only 10 to 15 percent
> of the software life-cycle...

This  is a favorite litany of the methodology mavens...but if you think  about
it,  it's  only  reasonable.  Why is coding only 10-15%?   Well,  one  set  of
reasons  is that the code produced is so often late, inefficient, not  robust,
inscrutable,  unadaptable,  and nonportable.  We spend the bulk  of  our  time
screwing around with code that's already written because it was lousy code  in
the first place...somehow I don't buy the idea that the solution is to improve
our  ability to screw around with the code!  Couldn't we try just a little  to
reduce  the need to screw around with it?  If we had done a good job with  the
10-15%  of  the  work,  a  lot of the  85-90%  remaining  wouldn't  have  been
necessary.

A couple more comments from Berard:

>    4) Software people have little faith in those concepts that come
>       before the coding phase. "How can anyone possibly describe
>       something which is not yet coded?", they reason...

Rubbish.  These aren't software people.

> It seems that most people have not understood the intentions of the
> U.S. Department of Defense (DoD) regarding the Ada effort. It is
> better engineered software that is desired, not merely "FORTRAN
> rewritten using the syntax and semantics of the Ada language." Too
> much emphasis has been placed on a tool (Ada) and not on the task
> (better software).

I  agree  with  this in a perverse sense:  I do not understand it  to  be  the
intent of DoD to produce better engineered software instead of a new language.
If that is what they desired, why did the requirements used in Ada development
(the  *man sequence) specify nitty details of syntax and semantics instead  of
focusing on requirements?  Why did they spend a decade screwing around with  a
programming  language before getting on to the environment?  Berard  is  quite
right  that  "too  much emphasis has been placed on a tool...and  not  on  the
task..."  -  and the nature of the development of Ada is the best  example  of
that misplaced emphasis.
--
Dick Dunn    {hao,nbires,cbosgd}!ico!rcd  (NOT CSNET!)   [phone]

---------------------------------------------------------------------------
Date:         Thu, 14 May 87 17:06:02 PDT
From:         "LT Scott A. Norton, USN" <[e-mail]>
Subject:      Re: Ada Education and Training - Part 3

In <[e-mail]>, hao!ico![e-mail] (Dick Dunn) remarked,

"A somewhat worse confusion over teaching 'programming' (I would rather a less
loaded  term  implying  'the  complete  process  of  constructing  functioning
software') immediately follows in Berard's article:"

I think the term he wants is "software engineering."

The  hard part about teaching software engineering is that the need  for  good
engineering  is  not apparent at the classroom level.  The programs  that  are
written  by  individuals in an undergraduate software course are less  than  a
thousand  lines.   They can be fully understood by one person.   They  do  not
undergo  maintenance, and do not have to adapt to changes in the  environment,
new  hardware,  or  changed specifications.  They usually do not  need  to  be
robust,  since  they  are  not used by many different  users  or  under  tight
constraints.

There is certainly a skill called "Programming." Selecting algorithms and data
structures,  making  loops  start  and stop  in  the  right  places,  avoiding
deadlocks;  they are all part of programming.  But, when you move to  programs
of  over one million lines, the problems you face are different.   Consistancy
of  the  specification becomes more difficult.  Testing and  debugging  become
more difficult ( some people say impossible ) Training new staff is  necessary
as the work progresses.  As people leave the project, the knowledge they  have
must  be passed down to the remaining staff.  Its not a difference  in  scale,
its a difference in kind.

If  you  teach a course in programming, you expect people to come  out  of  it
knowing how to write code.  Give them clear specifications and they should  be
able to write modules that will meet the specs.  But writing the specs, making
the  design  decisions  that determine the specs,  managing  the  programmers,
designing  tests,  chasing down the requirements that the  system  must  meet,
developing  the documentation, training the staff ( not how to code, but  what
the  project  is  supposed to do ) are part of the larger  world  of  software
engineering.   Its  a  different dicipline, and can't be taught  in  a  single
course.

Ada  is  supposed to be a language that makes it easier to  match  modules  to
specs,  design tests, eliminate some tacit assumptions about  interfaces,  and
make  code  more readable to ease the problems of bringing new people  into  a
project  or of doing maintenance.  Ada will be successful if it  improves  not
only coding, with its 15% of the load, but also these other areas.

  Programming : Software Engineering :: Word Processing : Writing a novel

When  I was in fourth grade, I thought that higher math was being able to  do,
like, really big long division problems.

LT Scott A. Norton, USN
Naval Postgraduate School
Monterey, CA 93943-5018
[e-mail]

---------------------------------------------------------------------------
Date: 6 May 87 08:56:00 GMT
From: mcvax!unido!tub![e-mail]
Subject: Re: Ada Education and Training - Part 3 - (nf)

In  an  otherwise  very reasonable article  in  comp.lang.ada,  ucbvax!EBERARD
(probably wrong address) writes:

() [...] K&R stresses the age old thinking which
() says that students of software must see, write, and execute code
() before anything else will be meaningful. Booch, on the other hand,
() stresses that students should know what they are doing before they
() attempt to write code. The K&R approach has its roots in software
() antiquity.

K&R  is a book about a programming language (a good one at that, by the  way).
Grady Booch's book is a book about software design in a programming  language.
These are two entirely separate subjects.  You can learn software  engineering
methods without learning the syntax of the Ada language at the same time,  and
you  can  learn  programming in C  without  simultaneously  learning  software
engineering methods.

A book that both teaches software engineering and a programming language seems
to  assume  that  the intended audience still needs to  learn  both  subjects.
Probably  a  reasonable assumption for many people who are now  learning  Ada.
Even  more  so  in  that Ada does have a few fine  points  that  only  can  be
unleashed in conjunction with knowledge about software engineering.

For  the C language novice in 1978 (when K&R was written), such an  assumption
would  have  been  invalid; I would have been bored if  K&R  had  placed  more
emphasis on the methods I already had been comfortable with in languages  like
Simula  etc.  that I had used before.  Its successor, the book about  the  C++
language  (Bjarne  Stroustrup 1986) still assumes some basic  knowledge  about
software  engineering when giving rules of thumb for the use of C++.  The  Ada
Reference  Manual (which is comparable to the reference sections of  both  K&R
and BS) also does not give any guidelines for design and testing methods  (and
we all agree it should not do that), but if you know anything about design you
immediately  understand  what packages and all these Ada concepts  are  about,
although these are complex enough that a good text will help you use the right
concept at the right time.

For the software engineering novice (as opposed to the C language novice  that
K&R  addresses), it is an interesting issue (e.g. see comp.edu)  whether  some
early  experience in simple programming helps understand software  engineering
concepts later or just helps people to start programming without design.

For  university  education, I still prefer first to learn to  put  letters  on
paper (i.e. programming) before learning to write entire books (i.e.  software
design).  However, just being able to put letters on paper does not make you a
writer (i.e. just being able to program does not make you a programmer).

Carsten Bormann, <[e-mail]> <[e-mail]> <[e-mail]>
Communications and Operating Systems Research Group
Technical University of Berlin (West, of course...)

==============================================================================
I. E. Ada Education and Training - Part 4
Date:  7 May 1987 04:27:38 PDT
Subject: Ada Education and Training - Part 4
From: Edward V. Berard <[e-mail]>

You  might  say that this is a discussion of the "dynamics of  Ada  technology
education." First, a few simple ground rules:

     1)  Education is different from training. To be crude about it,  training
is  what  you do with dogs, education is what you do with  people.  Seriously,
training of people works best with material which is extremely simple and  has
well-defined ("black and white") rules. If something can be done by rote, then
training  is  appropriate. Education of people is what is  required  when  the
rules  and  guidelines  of  a technology do  not  easily  lend  themselves  to
simplistic  ("black  and white") interpretations. There may be  many  possible
answers  to a single problem, and the identification of a specific  acceptable
set  of solutions will change depending on the particular constraints you  put
on the problem.

     2)  A  consequence  of the above is that education  may  require  certain
skills  and aptitudes that are not necessary for training. For example,  while
training might be appropriate for an electronics technician, education is what
is  required  for an electronics engineer (here, an  electronics  engineer  is
taken  to  mean  someone  with at least  a  bachelors  degree  in  electronics
engineering).

     3)  A  one-word definition for learning is: change.  Both  education  and
training require change. Often this change is not limited to the mental  state
of  the individual being educated or trained, but also extends to the  working
environment of that individual.

     4) Two very different paths are taken with the activities associated with
training and education. Since training is appropriate for situations requiring
little original human thought or judgment, the activities for which a human is
trained can often be easily automated. (Consider, for example, the training of
a  welder on an assembly line, and the eventual replacement of that welder  by
robots.)  Activities requiring education, on the other hand,  usually  involve
many  constantly  varying pieces of information. The  tools,  techniques,  and
methods  used  to handle situations for which education  is  appropriate,  may
themselves be quite complex. (Consider, for example the use of mathematics  to
calculate  the  dynamics  of the liquid fuel in  a  rocket  during  take-off.)
Typically,  situations requiring education lend themselves to  being  assisted
by, but not replaced by, automation.

There  are many players in the dynamics of Ada technology education.   In  the
case of U.S. Department of Defense (DoD) related efforts, the player  farthest
removed from the actual engineering of the Ada software is the customer, i.e.,
the  DoD. These people must be educated to the point where they  realize  that
training  is  NOT  appropriate  for Ada  technology,  but  that  education  is
required.

Many  of  us  have been denying the truth for years. We  may  have  felt  that
software production and maintenance required training, not education. This  is
not true. In fact, we should have been educating our technical and  managerial
personnel  in software engineering technology all along. The DoD's Ada  effort
is  the collection agent, and it is here to collect all our past due  software
engineering  education.  This  is  what  makes  Ada  technology  education  so
difficult.  Ada educators must not only teach the syntax and semantics of Ada,
but they must also educate their students in software engineering technology.

Closer  to home, we have the management of the organization requiring the  Ada
technology  education.  Management  must understand that they  must  help  and
encourage  Ada  technology education. They must provide the tools  and  people
necessary  for  good Ada technology education. They must let the  people  they
manage know that they take software seriously. It is management which can make
or break an Ada technology education effort.

Two  contrasting  examples  are  necessary here. At  Magnavox  in  Ft.  Wayne,
Indiana,  Management was seriously committed to the concept of Ada  technology
education:

     -   Management required themselves to go through the same  training  that
they put their technical staff through. This began to make them aware of  what
their technical could expect, and gave management a chance to ask questions in
context.

     -  Management had themselves trained first. This gave them the lead  time
to  begin preparing themselves and their staff for the changes which  were  to
come.

     -  Training was from 7:30 A.M. to 4:30 P.M. every day with one-half  hour
off for lunch. The class participants were already working on their labs  when
the  instructor arrived, and continued to work after the instructor  left  for
the day.

     -   No one was allowed to disturb the class. Unless it was a truly  life-
and-death  matter,  the best that anyone could do was to place a note  on  the
classroom door if they wanted to get the attention of a class participant.

     -  Management made sure that tools (e.g., an Ada compiler) were  procured
as early as possible, and that all that needed to, had access to the tools.

Another  organization (unfortunately, a well-known name in the  Ada  business)
had  management  which  did  about everything they could  do  to  prevent  Ada
education from happening:

     -  They delayed any kind of Ada technology education until shortly before
the coding was to start on the project.

     -   They did not allow their technical staff to participate in  classroom
activities on a regular basis. The number of students in the class room varied
from zero to about seven. (That's right, one day the instructor showed up, and
there were no students in the class for most of the day.)

     -  Management themselves kept well away from the classroom.

     -  During the first course which required the use of an Ada compiler, the
labs were delayed because the compiler was not even installed until the middle
of  the week. Even when the compiler was installed, it was installed so  badly
that it was all but unusable.

In  summary,  management  can  either  aid  the  dynamics  of  Ada  technology
education, or ensure the failure of Ada technology transfer.

Inside  the  classroom,  we have another set  of  dynamics,  specifically  the
relationship between the instructor and the students. A good instructor  knows
that  "education  is  a two-way street." The instructor  must  listen  to  the
students and be sensitive to their needs. The instructor must make  reasonable
attempts to reach most, if not all of the people in the class.

In  industry  (as  opposed  to  academia),  at  least  fifty  percent  of   an
instructor's  job  is  leadership.  An instructor  must  both  listen  to  and
understand  the  needs  of the people he or she  is  charged  with  educating.
However,  it is the instructor who must motivate and lead the class.  This  is
especially crucial in the case of Ada technology education.

Many students arrive at their first Ada class fully expecting a syntax course.
It  takes work and a good deal of persuasion to foster a desire  for  software
engineering as opposed to just learning the syntax of "just another language."
Some  Ada instructors are bullied by their students into providing  a  syntax-
only course. (I remember advising one of these instructors to "get up early on
Sunday morning and watch some of the TV evangelists for inspiration.")

Just getting into the classroom can be a challenge. The perspective instructor
must  successfully  persuade management that software engineering  is  a  good
thing, and is more important than Ada syntax.

The  instructor  must  not insult the intelligence of  his  or  her  students.
Students are fully capable of learning about software engineering on the  very
first  day  of  instruction. The belief that students must  know  code  syntax
before software engineering will make any sense is just plain wrong.  Software
engineering  instructors  have  two things going  for  them.  First,  software
professionals are very "goal oriented." Once proper goals are set  perspective
software engineers will strive for them. Second, most software engineers  want
to  to  the  best job they possible can. Showing how each  piece  of  software
engineering  technology aids in achieving this goal helps the  Ada  technology
instructor get the job done.

If, however, the instructor does not have a firm grasp of software engineering
technology,  he or she cannot hope to convey the technology to  the  students.
Merely  saying  the words "abstraction" and "information hiding" a  few  times
does  not  merit  being  called  a  software  engineering  approach.  Software
engineering  is  an enormous discipline encompassing  methodologies,  metrics,
mathematics, computer science, engineering disciplines, analytical and logical
thinking, communication skills, and other factors.

The  classroom dynamics I have just described also work in  academia.   Having
taught in college classrooms for regular college courses myself, I can  attest
that from the first day in their freshmen classes, college students are  fully
capable of understanding engineering disciplines. Consider the freshman who is
an  electronics  engineering  student.  He or she  may  have  entered  college
thinking  that  electronics engineering was little more than  "building  Heath
kits."   However,  engineering  students soon find themselves  in  classes  on
complex   analysis,  differential  equations,  physics,  chemistry,   statics,
dynamics, strength of materials, English, history, and other disciplines.

The  same kind of thinking holds for software engineering students.  They  may
enter a university thinking that software engineering is "glorified  hacking,"
but  they  are  just  as capable as the  electronics  engineering  student  of
learning  the  full  discipline, not just the least  significant  part  (i.e.,
coding).

                -- Ed Berard
                   [phone]

==============================================================================
I. F. Comments on Parts 1-4
Date: Mon 18 May 87 08:33:24-PST
From: [e-mail]
Subject: Thoughts provoked by Ed Berard's articles

     I always enjoy reading Ed Berard's articles because they are very thought
provoking. I usually agree with his observations and usually disagree with his
conclusions and recommendations. The recent 4 part discourse is not unusual in
that respect. While reading I mentally composed pages of response and wondered
which  responses, if any would be worthy of net resources.

     Then  I  received  a  paper from the SEI  by  Watts  S.  Humphrey  titled
"Software  Process Management" which contains a concluding thought that  seems
to  sum up my possible responses to Ed's articles. "There is a  definition  of
insanity that applies to software development. It is said that insane  persons
believe they can continue doing the same thing over and over and get different
results".  Upon  reading that I realized that I have been insane  most  of  my
career. I was insane when I expected engineers and managers to immediately see
the  advantage of transistors over vacumn tubes. I was insane when I  expected
them to see the advantage of computers over analog control. I was insane  when
I  expected  them  to see the advantage of Ada over Fortran until  I  said  to
myself  "Self- That's enough- Only deal with people who have already  accepted
that  there  is  an advantage and want help  realizing  the  advantage."

     This  happened  about the same time I started my own company  and  became
interested in profit. i.e.: There isn't much profit in missionary work. I have
a placard that says "Never try to teach a pig to sing: It will waste your time
and it annoys the pig." I believe that Ed is attempting to teach pigs to  sing
as I have often done. It is a form of insanity according to Humphrey. It takes
14 or so years for a new technology to be widely used in practice according to
SEI  (from  my  memory)  and  I  think it  will  be  so  for  modern  software
engineering/Ada  and there isn't much Ed or I can do about it.  Hopefully  the
SEI  can  do something about it through the  software  engineering  curriculum
design.

     So  Ed, my reaction to your discourse is to not criticize anyone for  not
immedialtely  seeing  the advantages of Ada, work with the ones  who  ask  for
help.  The  14 years will pass quickly and you'll be working on the  next  new
technology by then.

regards, sam harbaugh

---------------------------------------------------------------------------
Date:     Tue, 19 May 87 23:32 CDT
From:     "Pat Rogers, High Tech Lab" <[e-mail]>
Subject:  Software Engineering education, etc

Of all people, I think Niccolo Machiavelli said it best:

    Nothing is more difficult to carry out, nor more doubtful of
    success, nor more dangerous to handle, than to initiate
    a new order of things. For the reformer has enemies in all
    those who profit by the old order, and only lukewarm defenders
    in all those who would profit by the new order, this luke-
    warmness arising partly from ... the incredulity of mankind,
    who do not truly believe in anything new until they have
    had actual experience in it. (The Prince)

While Sam is correct in saying that missionaries do not usually turn a  profit
(recent televangelists notwithstanding), the missionary's position, if  you'll
pardon  the  pun, is that preaching to the choir is a lot easier  but  doesn't
address  the  audience most in need. This is actually a  worthwhile  attitude,
when  one considers the importance of some of the projects now  or  soon-to-be
underway.  More than a few people I've run across sound like the  people  with
which Machiavelli tangled, back in the early 1500's. (We can only assume  that
they  are not the same people.) In all seriousness, I don't always agree  with
the  things  I  read about Software Engineering education either,  but  it  is
important work, and is worthy of our support.

Regards,

Pat Rogers
PRogers@Ada20

.pa
============================================================================
II. The Human Element in Software Engineering
Date: 19 May 1987 04:31:13 PDT
Subject: The Human Element in Software Engineering
From: Edward V. Berard <[e-mail]>

There  is a good deal of wisdom in Sam Harbaugh's response to my recent  four-
part article on Ada Education and Training. I especially agree with his citing
of  the old adage: "Never try to teach a pig to sing: it will waste your  time
and  it  annoys the pig." In fact, another old saying: "Neither cast  ye  your
pearls  before swine." (Matthew 7:6) also came to mind regarding  the  natural
human tendency to reject new technology.

Technologists, in general, very often ignore the human element in  technology.
Many erroneously believe that it is technology that advances technology, when,
in fact, it is economics, politics, and sociology which are the main causes of
technological  change. Nowhere is the attempt to remove  human  considerations
from  technology so blatant as it is in the state-of-the-practice of  software
engineering.  Consider the following:

     1)  Although  people such as Barry Boehm have been telling us  for  years
that  the greatest improvements in technology will occur when we  improve  the
capabilities  of  the humans involved in the process (See the front  cover  of
Barry's  book, "Software Engineering Economics."), we continually ignore  this
advice. It seems we much more comfortable creating new automated tools than we
are  with measuring and improving the capabilities of the humans who  will  be
using the tools.

     2)  Sociologists  tell  us  that while bringing a  group  of  people  one
generation ahead in technology is difficult, bringing a group of people  ahead
two  generations of technology is all but impossible. In the area of  software
engineering,  the  state-of-the-practice  is easily two  or  more  generations
behind  the  state-of-the-art. This leads to some  interesting  results.   For
example,  while we currently possess the technology to increase  our  software
engineering  productivity by at least an order of magnitude, we cannot  expect
people to begin using this technology on a large scale for at least a  decade.
(Yes, Sam, I do agree with your observation.)

     3) New technology is seldom what people expect it to be. I used to give a
seminar on "Measuring and Improving Programmer Productivity." This seminar was
attended  chiefly by managers who expected me to tell them how to  make  their
programmers code faster in the programming language of their choice. When they
heard that the largest gains in productivity required such items as a shift to
fourth-generation  languages,  off-the-shelf software, and  smaller  technical
staffs,  the managers often refused to accept the facts, *even when  presented
with documented evidence supporting the facts.*

     4)  Even when people claim that they are ready to accept new  technology,
or  even to enthusiastically pursue new types of technology, they often  spend
enormous amounts of resources (in most cases, the majority of their resources)
"re-inventing or re-discovering the wheel." The concept of a simple literature
search is beyond most of the people in the software business today. Even those
who  are capable of even feeble scanning of the technical literature are  ill-
equipped  to  understand,  much less accurately  interpret,  what  they  find.
Recently,  someone  from  one  of the more  prestigious  centers  of  software
engineering  technology  transfer called to ask me about a  methodology.  This
person  was  part  of  a group  which  was  researching  software  development
methodologies.  This person was shocked when I told him that the work  he  was
charged  with had been done at least six times before. Indeed, in addition  to
numerous government sponsored reports available on the topic, five or six IEEE
tutorials, at least three hardback books, numerous foreign government studies,
and  several  publicly available industry and academic studies,  there  is  at
least one public seminar on the topic he was researching.

     5)  Technical  people seem very uncomfortable with  concepts  of  ethics,
morals,  and  responsibility. For example, few  software  engineering  courses
discuss  the  ethical  implications of a  managerial  or  technical  decision.
Although there are quite a number of courses and seminars about software  law,
most  deal  with  the  protection of copyrights -- as  opposed  to  the  legal
responsibilities  of  the  author of the software if  reasonable  use  of  the
software results in damage to the user.

As  I  have  stated before, most people are  more  comfortable  talking  about
technological change than doing anything about it. As a consultant, I am often
asked to pose solutions to any number of software engineering problems. It  is
a  sad fact that most of the people who pose the problems to me are  "insane."
(Insane by W.S. Humphrey's definition: "There is a definition of insanity that
applies  to software development. It is said that insane persons believe  they
can  continue doing the same thing over and over and get different  results.")
They  do  not want to hear the best, or even a correct, answer. They  want  to
hear more of the same.

Sam  is  also right on another point. The financial rewards of  being  on  the
leading edge of technology are meager at best. It is little comfort to realize
two  years  later  that you did indeed accurately  predict  the  technological
future, but will have to wait another two years to take economic advantage  of
your prediction. In Greek mythology, a woman named Casandra was cursed by  the
gods.  She was given the power to accurately predict the future. However,  the
gods made sure that no one would believe her predictions.

There  is, however, another view. Without people motivating and  cajoling  the
technical  population, there would be little work for people like Sam. So,  in
the  future, I will continue in my attempts to "teach pigs to sing."  I  guess
what  motivates  me is that I have had some success with  changing  pigs  into
quasi-rational  human beings.  (Another of the ancient Greeks, Homer, told  us
about Circe, a sorceress who turned men into animals. You might say that I  am
attempting to "reverse the curse.")

                -- Ed Berard
                   [phone]

.pa
===========================================================================
III. A. The DoD and Software Reuse - Part 5
Date: 15 Jun 1987 03:13:47 PDT
Subject: DoD and Software Reuse - Part 5
From: Edward V. Berard <[e-mail]>

Recently, I have had a number of conversations with DoD contractors  regarding
software reuse. While they all refuse to have their names used, they were very
honest with me about their opinions on the future of software reuse within the
DoD. Some points you might find interesting are:

     1.  Software  reuse is something which is virtually  meaningless  to  the
highest  levels  of management in most organizations doing business  with  the
U.S.  Department  of Defense (DoD). When these high-level  managers  are  told
about software reuse, they have one primary question: "How does it affect  the
bottom  line?" In other words, is this a concept which will make  the  company
more money? Given the current state of affairs, the answer is "no."

     2.  One of the reasons that the answer is currently "no,"  is  cost-plus-
fixed-fee (CPFF) contracting practices. Specifically, the more people put on a
project, the more money a contractor makes. Making reuse of software  actually
costs  the company money. Fixed price contracts, as they currently exist,  are
not  an  obvious  inducement  to reuse software  because,  as  more  than  one
contractor told me, "once we get a fixed price contract, we can always get the
government to give us additional money."

     3. At a briefing for contractors, an Army general said that "Ada appeared
to  be  "taking  off" in the commercial (non-military) sector."  "One  of  the
reasons  for  this,"  the  general continued, "was  because  of  the  software
reusability  benefits  that Ada provides. We think that our  contractors  will
also  see  these  same benefits and begin to make software  reuse  the  normal
practice."  Some of the contractors at the briefing felt that the general  was
very naive about the ways of government contracting to make such a statement.

So  what can we learn from the above? The first thing we must realize is  that
organizations which develop software are run by people whose primary  interest
is profit. "Ignoring the concepts of ethics and morality," one contractor told
me, "it does not seem to be currently in the best interests of a contractor to
develop  the  most  cost  effective  solution  for  any  government   software
contract."

We must also recognize that the commercial sector and the government  software
sector  are two very different animals. In the commercial sector, a  developer
often  pays all the costs for product development, hoping to more than  recoup
these  costs  based  on sales of the product.  With  this  type  of  scenario,
software  reuse makes a great deal of sense, i.e., the lower  the  development
costs,  the  lower  the risks and the greater the  potential  profit.  On  the
government  side,  the  software  developer  has  little  risk.  The  software
developer is being paid to develop a product, not to sell it. The greater  the
development costs, the more money the contractor makes. If the product  fails,
or  is  never  completed, the only one who loses is the  government.  (To  add
insult  to  injury, many contractors take the technology they  have  developed
under government contract and turn it into viable commercial products.)

"In  order  for software reusability to take hold  in  government  contracting
organizations," another contractor told me, "it must be made meaningful to the
highest  levels of contractor management." If they are aware of  it,  software
reusability  is  often  only  a  phrase to  the  upper  levels  of  contractor
management.  Since  it  is  the highest levels  of  management  who  can  most
effectively make software reusability a reality, the government must seek ways
to make software reusability "real" (and profitable) to these people.

                -- Ed Berard
                   [phone]
.pa
---------------------------------------------------------------------------
III. B. Comments on Part 5
Date: Mon 15 Jun 87 17:55:19-PST
From: [e-mail]
Subject: comments on Ed Berard's S/W reuse part 5

1.    I believe that the contractors skill at S/W reuse will provide  him  the
most advantage at bid time. The Government is *very* considerate of price when
awarding contracts. The contractors who are most skilled at reuse will win the
most contracts while those who bid all new code in order to collect the higher
fees will suffer.

2.    My  experience at a large DoD contractor was contrary to what  is  being
told to Ed. It was *very* difficult to get add-on money to either CPFF or  FFP
contracts  unless the Government was clearly getting additional value for  the
money.   I have heard extreme examples of rip-offs during the Vietnam war  but
all the time I worked there it was not under war emergency conditions and  the
Government was a *tough* customer.

3.   My  personal  opinion  is  to question the  data  being  told  to  Ed  by
"management".  My experience has been that administrative  management  doesn't
always know what is going on; The program manager does but he wouldn't tell so
unless  you have some clout (like work for the Defense Contract Audit  Agency)
you  are  not going to know "the facts". The work I recently did on  Ada  cost
modelling  showed us that very few people really knew what was going on.  Only
by careful recall on the part of the development manager could he remember why
certain  costs were unusual values. It was the unusual values that caused  him
to recall that reuse played an *important* part in S/W actual costs. Since  we
have now come full circle back to the value of reuse I'll sign-off.

regards, Sam Harbaugh

--------------------------------------------------------------------------
Date: 16 Jun 1987 02:17:55 PDT
Subject: Putting Software Reuse in the RFP
From: Edward V. Berard <[e-mail]>

I  have  had  some  interesting  responses  to  my  most  recent  posting   on
reusability.  Some  are along the lines of "you are belaboring  the  obvious."
Others  are  similar to the response that Sam Harbaugh provided,  i.e.,  "your
'facts'  are  not  on  target."  What  this  mixture  of  responses  seems  to
demonstrate  is  the  confusion over the "real" impact of  software  reuse  on
government procurements.

One  point  that  is  worth mentioning is that lower price  alone  is  not  an
indicator  of  software  reuse. The government needs to  know  what  they  are
getting for their money. For example, one could bid a lower price by  limiting
the  scope  of  the delivered product, underestimating the  actual  costs,  or
"buying"  a contract (purposely bidding less than what you know what the  true
cost of the contract will be, most often for some future profit motive).

One  approach  that  some government agencies have begun to  use  is  to  make
software reuse highly visible in the original RFP (Request For Proposal).  For
example,  bidders  are required to provide some estimate of the  size  of  the
delivered software -- typically in "lines of code."  In addition, the  bidders
must  provide an estimate of how much reusable software will  be  incorporated
into  the  delivered  product, and they must also describe  how  this  "reused
software" will impact the cost, quality, etc. of the product.

Given  this, and other, information, the requester can begin to get  a  better
understanding of what the different bidders are proposing.  Suppose one bidder
estimates  the  size  of  project at "50,000 lines  of  code,"  while  another
estimates the size to be "100,000 lines of code."  There could be many reasons
for the difference, but it will be likely that the bidder with fewer lines  of
code will submit a lower bid.

If,  however, two, or more, bidders provide similar estimates as to  the  size
and  scope of the delivered product, a more accurate picture of the impact  of
software  reuse  is  possible. Everything else being equal (Yes,  I  know,  it
seldom  is.), the bidder who plans to incorporate significantly more  reusable
software into the delivered product should be able to submit the lower bid.

One  government agency told me that they recently acquired an Ada  application
which  was  about 100,000 "lines of code" in size with an expended  effort  of
"significantly less than a man-year."  This was possible because of the  heavy
reuse of software on the project.  (One very large company I talked with, told
me  that they might "optimistically" bid this same contract at "20  man-years"
of effort.)

                -- Ed Berard
                   (301) 695 - 6960

---------------------------------------------------------------------------
Date:     Tue, 16 Jun 87 11:14 EDT
From:     Pete Schilling <"VAXTSD::SCHILLING1%atc.alcoa.com"@RELAY.CS.NET>
Subject:  Software Reuse

This  may  seem  incredibly naive to those who have  long  experience  in  the
Defense contracting game, but it deserves saying anyway:

If the benefits of software reuse are real, then --
     -  A  product that makes significant reuse of software  should  be  ready
sooner than one that represents all new code.
     -  Saying  than another way, a product that makes  significant  reuse  of
software could be started later in the system development cycle.
     -  The reliability of a product that makes significant reuse of  software
should be higher that an equivalent product that represents all new code.
     - Other quality characteristics of a product that makes significant reuse
of  software should be much more predictable than one that represents all  new
code.
     -  The  maintenance cost of the product that makes significant  reuse  of
software should be lower.

If all of the above is really true, then the customer should be willing to pay
MORE for a product that makes significant reuse of software than for one  that
represents all new code.

Pete Schilling            CSNET:    [e-mail]
Technical Specialist        PHONE:    [phone]
Process Control and        PAPER MAIL:    Aluminum Co. of America
   Computer Technology Divn.        Alcoa Center, PA  15069
Alcoa Laboratories            USA

---------------------------------------------------------------------------
Date: Wed, 17 Jun 87 07:43:22 EDT
From: [e-mail] (D. Schimsky)
Subject: Re:  Software Reuse

As  a "Government" manager of major software developments, let me  offer  that
most of comments I've seen here relative to "re-use" appear academic.

1.  No,  I would NOT pay more for a product that takes  advantage  of  re-use,
since  virtually  my  entire  concern  is  to  LOWER  the  price  of  software
development.   There  is no way, short of pushing my nose in it, that  I  will
believe  a paper analysis showing me how much I will save tomorrow if  only  I
give you more today.

2.  Short of absolute mandate (translate to "I order you to...") the  detailed
methods employed in the development of software are made on a very local level
by  the  people first in line for the responsibilty.  These  are  the  Project
Engineers,  or Program Officers, or some equivalent title.  I believe  I  know
what  their opinion is concerning re-use, but it would be interesting to  hear
them speak.

3.  By  what  magic do you expect an organization as large  and  diverse  and,
sometimes,  divergent, to adopt a methodology that begs  for  standardization,
cooperation, flexibility and a non-parochial attitude, when you would do  well
to find one, small, isolated group, anywhere, doing the same?

----------------------------------------------------------------------------
Subject: Re:  Software Reuse
Date: Thu, 18 Jun 87 12:55:43 EDT
From: Bob Munck <[e-mail]>

I don't know if I've ever seem a more straightforward explanation of the DoD's
Software Crises than this:

> As a "Government" manager of major software developments, ... There
> is no way, short of pushing my nose in it, that I will believe a
> paper analysis showing me how much _I_ will save tomorrow if only I
> give you more today.

Remember  that the _I_ (underlining mine) is really "the poor slob  who'll  be
maintaining  this system years after I get a job in Industry."  Remember  too,
that  EVERYBODY'S project is too important (major) to take the risk  of  being
the first to use any new technique.

Of  course, with FORTRAN, JOVIAL, CMS-2, and/or the Chinese Army  approach  to
programming, there's no risk.  We KNOW that it will be late, over budget,  and
buggy.  No surprises, no risks.

                      -- Bob Munck, MITRE

.pa
----------------------------------------------------------------------------
Date: 18 Jun 87 08:46:36 GMT
From: mcvax!ukc!dcl-cs![e-mail]  (Craig Wylie)
Organization: Department of Computing at Lancaster University, UK.
Subject: Software Reuse  --  do we really know what it is ?

There have been a couple of articles recently on Software Reuse and its likely
acceptance by Defence Contractors.  In considering Software Reuse in  general,
not  just with reference to Ada and DoD, do we know what it is? The  scale  of
software that Ada allows the programmer to reuse seems to be primarily that of
the  package (in Modula-2  the Module). Is this sufficient? If we leave  aside
for the time being the question of whether Ada is an object oriented  language
and  accept that if it isn't then you can do a reasonably good job faking  it,
reuse  in  Ada  seems  to be stuck at the level of  the  Abstract  data  type.
Furthermore  the  lack  of any easy (or apparent) way to derive  WHAT  an  Ada
program  is doing rather than HOW it is doing it, does put a large  amount  of
the responsibility for recovering reusable components on the programmer.

In summary I would like to offer a few statements for discussion to see if  we
can clarify reuse.

1.    We don't really know what it is.

2.    It probably isn't a thing at all, but rather a collection of things
    depending on the scale at which the reuse is to take place.

3.    Languages such as Ada and Modula-2, and imperative languages in
    general are unsuitable for writing reusable software because of
    their concentration on the HOW rather than the WHAT.

4.    Reuse of Design isn't considered at all by any current applications
    language.

5.    Nobody can force programmers to write good reusable code.

6.    Even if they do write reusable code how the **** do we ever find it
    again so that we can reuse it ?


All responses appreciated.

Craig.
UUCP:     ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster,
DARPA:     craig%lancs.comp@ucl-cs          |      Department of Computing,
JANET:     [e-mail]           |      Bailrigg, Lancaster, UK.
Phone:     [phone] Ext. 4476         |      LA1 4YR

---------------------------------------------------------------------------
Date: Sat 20 Jun 87 12:27:45-PST
From: [e-mail]
Subject: reuse - suggestion to include usage history in metrics

     You  don't write reusable code, you write useable code, use it,  then  it
becomes  reusable. The reason I make such a statement is to set the stage  for
making  the  suggestion that reuseable code's useage history is  an  important
attribute  and one which I would like to see the reuseabilty  research  people
include in their reusability metrics.
     For  examples just think of selecting a spreadsheet, etc., to reuse  (buy
at the software store).
     I  suspect  that  most  software being touted as  reuseable  today  (  at
Simtel20 repository for instance) is not reuseable because it hasn't been used
for the first time.

regards, sam harbaugh

---------------------------------------------------------------------------
Date: 22 Jun 1987 04:00:27 PDT
Subject: Software Reuse -- We Know More Than You Think
From: Edward V. Berard <[e-mail]>

This is response to an honest question by Craig Wylie. Wylie asks a series  of
general questions about software reuse. He has also inadvertently tripped over
one  of my pet peeves. Let me quietly explain, and then I will get on with  my
answer to his questions.

******************** Personal tirade -- Can be ignored ************

We  often ignore the technical nature of software engineering. By that I  mean
that we assume there is little to software engineering other than writing code
and opinion. Concepts which are accepted as normal practice in other technical
disciplines  (e.g., literature searches, the application of  mathematical  and
engineering disciplines, and quantitative metrics) are not yet accepted by the
masses as being relevant for software engineering.

Take the issue of software reuse. Ignoring any work in this area prior to Doug
McIlroy's  article  at  the  1968 NATO  Conference  on  Software  Engineering,
software  reusability  has  a history of almost two decades  of  research  and
implementation.  This  research and implementation knows  no  geographical  or
political bounds. For example, the Japanese have an organization called  SIGMA
to deal with software reuse.

The  IEEE  has recently published and entire tutorial on  software  reuse.   A
number  of  recent issues of IEEE Software have carried articles  on  software
reuse. Two entire issues of the IEEE Transactions on Software Engineering were
devoted  to  software  reusability.  Even a  feeble  search  of  the  software
engineering  literature would turn up hundreds of articles on the topic.  (The
quality  of  these articles ranges from dismal to excellent.)  Many  of  these
articles offer definitions, metrics, taxonomies, and reusability systems.

Some of the items which we now know about software reusability are:

     -   Much  more than source code can be reused. In fact,  designs,  plans,
test data, and documentation (among others) can be reused. The smallest  gains
in productivity, reliability, etc., are obtained by only reusing source  code.
Reusing  the  documentation  associated with "reusable  source  code"  greatly
enhances any gains associated with merely reusing the source code.

     -   Reusability is not a concept that is limited to the coding  phase  of
the  software life-cycle. It must be a highly visible item  from  requirements
analysis to the retirement of the product.

     -   Research  seems  to indicate, and practice seems to  show,  that  the
majority of many software products can be assembled from reusable components.

     -  There are any number of metrics associated with software reuse.   They
include metrics which measure the sheer bulk of source code and  documentation
reused  in  an application, to metrics which measure the affects  of  software
reusability, e.g., software productivity metrics.

My  image of the current state-of-the-practice in software engineering is  one
of  a  series of blind and deaf individuals surrounded by massive  amounts  of
software engineering technology. All too often when some of this technology is
brought  to  the attention of one of these "handicapped"  individuals,  it  is
dismissed as "buzzwords," "academic," "theoretical," or "mere opinion."

*********************** End of tirade *******************************

Wylie  asks if we know what software reuse is. There are two answers  to  this
question.  The vast majority of today's software practitioners either  do  not
know what it is, or assume that it is "yet another buzzword." There is a small
minority of individuals and organizations who are researching and implementing
various  aspects of software reuse. [I am reminded of the anecdote  about  the
monks  in their abbies who preserved the knowledge of mankind during the  dark
ages while "the winds of ignorance howled outside."]

No, Ada's package concept is not enough. Grady Booch has been pointing out for
years  that  some  higher  level  concept  (e.g.,  Rational's  subsystems)  is
necessary. By the way, virtually all existing programming languages (with  the
exception of some very high-level fourth-generation languages) lack attributes
which make them directly applicable to programming-in-the-large.

Reuse in Ada is not "stuck at the level of the abstract data type."   However,
few software engineers know how to go beyond this concept (in any language).

There are a number of ways to derive the "what" from a piece of Ada  software,
and  to divorce this from the "how." The mechanisms for doing this range  from
crude  (e.g.,  include  the  "what" in the  comments),  to  innovative  (e.g.,
consider  David Luckham's ANNA). Further, the recovery of reusable  components
can be handled in a number of ways:

   -  level 0: the use of a hierarchical file system

   -  level 1: the use of a relational DBMS (data base management
      system) or a hypertext system

   -  level 2: the use of an expert system or some other artificial
      intelligence tool

   -  level 3: incorporation of reusable components in an application
      generator (a type of fourth-generation language)

These   approaches  have  also  been  modified  to  include  such  things   as
documentation, test data, designs, and plans as well as source code.

Software  reusability  technology  is indeed a collection  of  things.   These
things   include   reusable  components,  taxonomies,   reusability   systems,
composition  concepts,  methodologies,  and others. This  technology  is  more
coupled  with the size of the software product than it is with "the  scale  at
which the reuse is to take place."

The  issue of language suitability for reuse is an interesting  one.   Stating
that   imperative  languages  are  unsuitable  for  reuse  shows  a  lack   of
understanding of software reuse technology. (But then again, I have heard  any
number  of Ada people make similar misstatements about languages such as  LISP
and most fourth-generation languages.) One might re-phrase the observation  by
stating  that the mere use of the Ada language does not guarantee  reuse.  The
language  must  be accompanied by software reuse technology (e.g.,  tools  and
methodologies).

One  item  which seems to have escaped the understanding of many  in  the  Ada
community  is that one of the primary motivations behind the Ada  language  is
"to  build tools to build tools." Ada was designed with the intention that  it
be used as a bootstrap. Specifically, it is to be used to create libraries  of
reusable components (the first "tools").  These reusable components are to  be
used  to  create  fourth-generation languages and  "software  factories"  (the
second  "tools").  Using the Ada language as if it were  Pascal,  C,  FORTRAN,
COBOL, or assembly language is tantamount to abuse.

Software  design  methodologies do play an important part in  software  reuse.
Some methodologies enhance software reuse, others discourage it. We have known
for  some  time that software designs should be constructed so that  they  can
easily  be modified. We are only now beginning to understand that by  bringing
software reusability issues to the first phases of the software life-cycle, we
can  greatly enhance the impact of software reusability. Finally, by  studying
the  designs  of many systems within a particular application  domain  we  are
finding  designs  are very much reusable, e.g., consider the  basis  for  many
fourth-generation languages.

Nobody   can  force  programmers  to  write  good  reusable   code.   However,
programmers,  as  a whole, want to do a good job and are  very  goal-oriented.
Getting  programmers to write good reusable code is in part a  motivating  and
educational process.

Finally,  in  addition to the technical problems which must be  addressed,  we
have  to consider many other connected issues. Political,  managerial,  legal,
cultural,  financial,  marketing,  and  productization  issues  must  also  be
considered.

                -- Ed Berard
                   [phone]

---------------------------------------------------------------------------
Date: 22 Jun 87 18:59:41 GMT
From: [e-mail]  (Lawrence Crowl)
Organization: U of Rochester, CS Dept, Rochester, NY
Subject: Re: Software Reuse  --  do we really know what it is ?

In article <[e-mail]> [e-mail] (Stanley Shebs) writes:

]... software people fume and gnash their teeth over "wasted space". ...  All
]the techniques for modules, objects, etc, tend to slow things down.  Again,
]software types tear their hair out and vow to recode everything into one
]assembly language procedure.  Worse, other software types admire them for
]doing so!  ...
]
]In article <[e-mail]> [e-mail] (Lawrence Crowl) writes:

>>In article <[e-mail]>
>>[e-mail] (Craig Wylie) writes:
)))3.    Languages such as Ada and Modula-2, and imperative languages in
)))    general are unsuitable for writing reusable software because of
)))    their concentration on the HOW rather than the WHAT.
>>
>>Clearly, we need more concentration on WHAT, but we should not abandon the
]                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
>>efficiency of HOW.
] ^^^^^^^^^^
]
]QED!

Let  me clarify my position.  I can specify a sort as a set of predicates  and
let  the system figure out how to satisfy those predicates.  This is the  WHAT
approach  used  in languages such as Prolog.  Another approach is to  write  a
algorithm  for  sorting,  e.g. quicksort.  This is the HOW  approach  used  in
languages  such  as Ada.  Yes, the packaging of the sort will result  in  some
loss  of efficiency.  However, it will be substantially faster than  the  WHAT
approach.  I am advocating an approach in which a package interface  describes
WHAT and the implementation of the package describes HOW.

Because  I wish to keep the macro-efficiency of algorithmic languages, do  not
accuse me of wishing to keep the micro-efficiency of hand-tuned assembler.

]3. In general, hardware types have standards for every imaginable sort of
]interface, and they stick to them remarkably well.  You can plug boards into
]a standard bus with only a small chance of sparks flying everywhere as the
]boards fry.  In software, standards are strictly for lip service to managers;
]only a novice would consider combining programs from several different
]sources without planning a few hours or days of debugging!

Programmers  to this sort of program combination many times a day in the  Unix
shell.   There  ARE approaches to software reuse that CAN work.   We  need  to
provide this kind of capability within a language.

]In short, I believe there are no technical problems or issues with reuse;
]it's the software culture that has to change.  At present, the prevailing
]attitude is that the densely-coded, highly-optimized, do-everything program
]is a sort of ideal to which everyone aspires.  Until this attitude changes,
]software reusability will continue to be a bad joke among those who actually
]write programs.

There  are  technical  problems.  For instance, how do  you  insure  that  the
parameters to a generic package are appropriate.

Performance will always be a goal.  However, it must be balanced against cost.
Most  programming  done  today  is in a high-level  language.   In  the  early
sixties,  most programming was done in assembler.  So, the  software  attitude
has changed.

Modular code also allows changes in representation that can lead to orders  of
magnitude  performance improvements.  Non-modular code strongly inhibits  such
representational changes.  In short, the micro-efficiency of non-modular  code
leads to the macro-INefficiency of poor algorithms and representations.

)))5.    Nobody can force programmers to write good reusable code.
>>
>>True.  But no one need buy code that is not both good and reusable.  I
>>believe there is a market for such code.
]
]Manufacturers seem to think their interest is in maintaining secrecy of code.

Again, let me clarify.  I meant that the reusable software would be written by
software houses and sold to companies which write applications.  For instance,
Reusable  Software Inc. sells a sort package to Farm Software Inc. which  uses
it in its combine scheduling program.  Farm Software Inc. need not divulge its
algorithms or its use of packages written by Reusable Software Inc.

]Customers only care about speed and features.  Read Infoworld and see if they
]ever say anything positive about a program that is slower but more modular.

You forgot cost.  Modular code will cost substantially less in the long run.

  Lawrence Crowl        716-275-5766    University of Rochester
            [e-mail]    Computer Science Department
 ...!{allegra,decvax,seismo}!rochester!crowl    Rochester, New York,  14627

----------------------------------------------------------------------------
Date: 22 Jun 87 15:40:19 GMT
From: [e-mail]  (Stanley Shebs)
Organization: PASS Research Group
Subject: Re: Software Reuse  --  do we really know what it is ?

In article <[e-mail]> [e-mail] (Lawrence Crowl) writes:

>In article <[e-mail]>
>[e-mail] (Craig Wylie) writes:
>>1.    We don't really know what it is.
>
>Well, I find a glimering of re-use in reading Knuth's books.  I will point at
>an analogy though.  Board level designers constantly use circuits designed by
>others.  They are packaged in integrated circuits.

An interesting analogy.  It says a lot about prevailing software culture:

1.  Available chips do not always meet requirements exactly.  For instance,  a
board might need 3 NAND gates, but the 7400 has 4.  EEs just ignore the  extra
gate,  or tie its pins to something stable.  In a similar situation,  software
people fume and gnash their teeth over "wasted space".

2.  Running wires around boards loses some performance, relative  to  cramming
everything onto a single chip.  All the techniques for modules, objects,  etc,
tend  to slow things down.  Again, software types tear their hair out and  vow
to  recode  everything  into one assembly language  procedure.   Worse,  other
software  types admire them for doing so!  Come to think of it, the advent  of
VLSI  tools  promotes  the same idea for hardware, and we're  seeing  lots  of
specialized chips these days...

>>3.    Languages such as Ada and Modula-2, and imperative languages in
>>    general are unsuitable for writing reusable software because of
>>    their concentration on the HOW rather than the WHAT.
>
>Clearly, we need more concentration on WHAT, but we should not abandon the
                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
>efficiency of HOW.
 ^^^^^^^^^^

QED!

3.  In  general, hardware types have standards for every  imaginable  sort  of
interface, and they stick to them remarkably well.  You can plug boards into a
standard  bus  with  only a small chance of sparks flying  everywhere  as  the
boards fry.  In software, standards are strictly for lip service to  managers;
only a novice would consider combining programs from several different sources
without planning a few hours or days of debugging!

In short, I believe there are no technical problems or issues with reuse; it's
the software culture that has to change.  At present, the prevailing  attitude
is  that the densely-coded, highly-optimized, do-everything program is a  sort
of  ideal  to which everyone aspires.  Until this attitude  changes,  software
reusability  will  continue to be a bad joke among those  who  actually  write
programs.

>>5.    Nobody can force programmers to write good reusable code.
>
>True.  But no one need buy code that is not both good and reusable.  I believe
>there is a market for such code.

Manufacturers seem to think their interest is in maintaining secrecy of  code.
Customers only care about speed and features.  Read Infoworld and see if  they
ever say anything positive about a program that is slower but more modular.

>  Lawrence Crowl        716-275-5766    University of Rochester

                            stan shebs
                            [e-mail]

.pa
----------------------------------------------------------------------------
Date: 23 Jun 87 17:28:26 GMT
From: [e-mail]  (Stanley Shebs)
Organization: PASS Research Group
Subject: Re: Software Reuse  --  do we really know what it is ?

In article <[e-mail]> [e-mail] (Lawrence Crowl) writes:

>>>Clearly, we need more concentration on WHAT, but we should not abandon the
>]                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
>>>efficiency of HOW.
>] ^^^^^^^^^^
>]
>]QED!
>
>Let me clarify my position.  I can specify a sort as a set of predicates and
>let the system figure out how to satisfy those predicates.  This is the WHAT
>approach used in languages such as Prolog.  Another approach is to write a
>algorithm for sorting, e.g. quicksort.  This is the HOW approach used in
>languages such as Ada.  Yes, the packaging of the sort will result in some
>loss of efficiency.  However, it will be substantially faster than the WHAT
>approach.  I am advocating an approach in which a package interface describes
>WHAT and the implementation of the package describes HOW.
>
>Because I wish to keep the macro-efficiency of algorithmic languages, do not
>accuse me of wishing to keep the micro-efficiency of hand-tuned assembler.

I  wasn't accusing anybody of anything, just pointing out that like any  other
culture,  the software culture is very pervasive and people in it  (us)  don't
always  recognize when we're behaving according to those cultural norms.   For
instance, if I were to post some inefficient sort to the net, there are  maybe
ten  computer people in the world who could look at it and not get at least  a
twinge of "Gee, why not use a better algorithm?"  As I said, it's part of  the
culture.  Not completely bad, but frequently dominates our thinking.

Your  typical  serious  C  hacker will get unhappy about  the  overhead  of  a
function  call, let alone the extra functions involved in  "packaging"!  After
several  years of extensive Lisp hacking, I've managed to overcome  resistance
to  defining lots of little data abstraction functions, and only  feel  guilty
once in a while :-).  An additional obstacle to using the "packaging" is  that
in  the  past,  some systems (such as Simula and  Smalltalk)  were  orders-of-
magnitude  slower than procedural languages, and there is perhaps a  lingering
perception that data abstraction costs a lot in performance.

Requiring  both  WHAT  and HOW is a pretty controversial  thing  to  do.   The
biggest  problem to me is the potential for inconsistency, since  many  things
will be stated twice, but in different terms.  That's the rationale for making
the  computer  figure out the HOW itself, but that is an elusive  and  perhaps
unreachable goal.  (Doesn't stop me from trying though!)

>Programmers [do] this sort of program combination many times a day in the Unix
>shell.  There ARE approaches to software reuse that CAN work.  We need to
>provide this kind of capability within a language.

Unix  is a counterexample, that's why I didn't mention it :-).  A closer  look
is worthwhile.  Unix tools offer basically one interface - a stream of  bytes.
More  complicated interfaces, such as words, nroff commands, or  source  code,
are less well supported; it's unusual to be able to pass C source through many
filters  in  the  way that data files can be passed.  Also, at  least  in  the
groups of Unix users I've observed, pipes and filtering sequences longer  than
about  3 stages are relatively uncommon, and are about as difficult  for  many
people to compose as a C program.  Of course, my sample is not scientific, and
I'm  sure there are lots of Unix hacks that will be glad to tell me all  about
their 15-stage pipe processes!

What other *working* approaches are there?

>There are technical problems.  For instance, how do you insure that the
>parameters to a generic package are appropriate.

Use  something higher-level than Ada?  This seems like an issue only for  some
languages, not a major obstacle to reuse.

>Performance will always be a goal.  However, it must be balanced against cost.
>Most programming done today is in a high-level language.  In the early sixties,
>most programming was done in assembler.  So, the software attitude has changed.

This is how us language people justify our salaries.  On the other hand,  I've
been wondering if the change was caused by other factors not directly  related
to level of language, such as sites getting a wider variety of hardware  (thus
making non-portable assembly language impractical).  C is very popular for new
applications  nowadays,  but  many  consider C  to  be  a  "portable  assembly
language".

>Modular code also allows changes in representation that can lead to orders of
>magnitude performance improvements.  Non-modular code strongly inhibits such
>representational changes.  In short, the micro-efficiency of non-modular code
>leads to the macro-INefficiency of poor algorithms and representations.

I agree 100% (especially since my thesis relates to this!)  BUT, flaming about
the  wonders of data abstraction is not going to change anybody's  programming
practices.  Demonstrations are much more convincing, although a DoD project to
demonstrate  reusability is probably much less influential than Jon  Bentley's
CACM column.  Many recent C books have been introducing substantial  libraries
for reuse, although the books' stated policies on copying are not  consistent.
More of this sort of thing would be great.

>Again, let me clarify.  I meant that the reusable software would be written by
>software houses and sold to companies which write applications.  For instance,
>Reusable Software Inc. sells a sort package to Farm Software Inc. which uses
>it in its combine scheduling program.  Farm Software Inc. need not divulge its
>algorithms or its use of packages written by Reusable Software Inc.

I  hadn't  thought  about that.  Here's my reaction as a  Farm  Software  Inc.
programmer  -  "How  do I know if their stuff is good  enough!?  ...  But  the
interface  isn't  right! ... How can we fix the bugs without  sources!"  Reuse
can't  happen  until the seller *guarantees* critical characteristics  -  they
have  to be able to say that their sort package will sort M data values  in  N
seconds, and that the software will have bugs fixed within a certain number of
days  of being discovered, and so forth.  This is old hat for other  kinds  of
engineers,  but software companies these days will only promise that there  is
data on the disk somewhere :-(.  (I'm sure there are places that will  certify
performance - anybody got good examples?)

>[...] Modular code will cost substantially less in the long run.

I sort of believe that too, but it's hard to substantiate.  Anecdotes are easy
to  come by, but this is a field where cost depends primarily  on  programming
skill, and we don't have a precise measure of that skill.  The other cost  win
is  when  a module can be used in some other program, but the  extra  cost  of
making code reusable can only be justified if your company has another program
to use it in!

BTW, at Boeing I proposed an engineer-maintained library of  aerospace-related
subroutines, so people didn't have to continually reinvent spherical  geometry
formulas, Zakatov equations, and the like.  But management rejected the  idea,
because  it  would be "too difficult to coordinate" (it was  supposed  to  cut
across individual projects).  No mention of costs...

People  interested  in  promoting software reuse should  look  at  how  expert
systems  developed as a field.  Although the first ones appeared in  the  mid-
70s, it wasn't until 1980 when the expert system R1 that configured Vaxen  for
DEC was published.  DEC claimed to have saved millions of dollars in the first
year   of  using  it.   From  then  on,  the  expert  system   business   grew
exponentially, although it's not clear whether anybody else has ever  profited
from an expert system so dramatically...

>  Lawrence Crowl        716-275-5766    University of Rochester

                            stan shebs
                            [e-mail]

----------------------------------------------------------------------------
Date: 25 Jun 87 17:32:39 GMT
From: [e-mail]  (Dennis Doubleday)
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Subject: Software Reuse

In article <[e-mail]> [e-mail] (Stanley Shebs) writes:

>An interesting analogy.  It says a lot about prevailing software culture:
>
>1. Available chips do not always meet requirements exactly.  For instance,
>a board might need 3 NAND gates, but the 7400 has 4.  EEs just ignore the
>extra gate, or tie its pins to something stable.  In a similar situation,
>software people fume and gnash their teeth over "wasted space".
>

I've seen this standardized circuits analogy to software packages a number  of
times, and I don't really buy it.  Software people are attempting to deal with
a  much  larger  and less well-defined problem domain  than  hardware  people.
Otherwise,  we wouldn't even need software.  We could just design hardware  to
handle every application.

>2. Running wires around boards loses some performance, relative to cramming
>everything onto a single chip.  All the techniques for modules, objects, etc,
>tend to slow things down.  Again, software types tear their hair out and
>vow to recode everything into one assembly language procedure.

Performance is an important issue in many time-critical applications.  I don't
know anybody who wants to code everything in assembler.  I do know people  who
are  WILLING to code in assembler if it's the only way timing constraints  can
be met.

>In short, I believe there are no technical problems or issues with reuse;
>it's the software culture that has to change.  At present, the prevailing
>attitude is that the densely-coded, highly-optimized, do-everything program
>is a sort of ideal to which everyone aspires.

I  don't  think  you're up to date on what's happening, at least  in  the  Ada
community.   I just completed a 13.5K source line Ada program, of  which  7.5K
source lines were contributed by reusable utility packages that I got from the
Ada repository (abstract string, stack, list, counted ordered set, and  binary
tree  data  types  as well as packages for  command  line  interface,  lexical
analysis of Ada, and parsing).


UUCP:    seismo!mimsy!dday                        Dennis Doubleday
CSNet:    dday@mimsy                 University of Maryland
ARPA:    [e-mail]             College Park, MD 20742
Fan of: Chicago Cubs, Chicago Bears, OU Sooners     [phone]

---------------------------------------------------------------------------
Date: 2 Jul 87 07:55:43 GMT
From: mcvax!prlb2!crcge1![e-mail]  (Drew Adams)
Organization: Laboratoires de Marcoussis (CGE) - France
Subject: Re: Software Reuse  --  do we really know what it is ?

Let me play provocateur and recommend a little known paper introducing another
point of view regarding software reusability and modularity:

Hughes, John, "Why Functional Programming Matters", Report 16, Programming
        Methodology Group, University of Goteborg and Chalmers
        University of Technology, Goteborg, Sweden, 1984,
        ISSN 0282-2083

Here's the abstract:

     "As software becomes more and more complex, it is more and more important
to  structure  it well.  Well-structured software is easy to  write,  easy  to
debug,  and  provides a collection of modules that can be  re-used  to  reduce
future  programming costs.  Conventional languages place conceptual limits  on
the way problems can be modularised.  [Purely f]unctional languages push those
limits back.  In this paper we show that two features of functional  languages
in  particular,  higher-order functions and lazy  evaluation,  can  contribute
greatly  to modularity.  As examples, we manipulate lists and  trees,  program
several  numerical  algorithms,  and implement the  alpha-beta  heuristic  (an
algorithm from Artificial Intelligence used in game-playing programs).   Since
modularity  is  the key to successful programming, functional  programming  is
vitally important to the real world."

Hughes  argues  that  the usual "advantages"  of  declarative  languages  over
imperative  ones  (no  assignment, no side effects, no flow  of  control)  are
negative  expressions of some of the problems with imperative  languages,  but
that  they  leave  unexplained 1) why these problems are  problems  and,  more
importantly,  2)  what  are  the  real  POSITIVE  advantages  of   declarative
programming.  To quote from the introduction:

     If  omitting  assignment statements brought such enormous  benefits  then
FORTRAN  programmers  would  have been doing it for twenty  years.   It  is  a
logical  impossibility to make a language more powerful by omitting  features,
no matter how bad they may be.

     Even a functional programmer should be dissatisfied with these  so-called
advantages,  because  they  give  him  no help  in  exploiting  the  power  of
functional  languages.   One  cannot write a  program  which  is  particularly
lacking  in assignment statements, or particularly referentially  transparent.
There  is no yardstick of program quality here, and therefore no ideal to  aim
at.

     Clearly  this characterisation of functional programming  is  inadequate.
We must find something to put in its place - something which not only explains
the power of functional programming, but also gives a clear indication of what
the functional programmer should strive towards.

Hughes  finds that the importance of functional languages is that  they  allow
program  modularisation in ways which imperative languages cannot.   To  quote
again:

     "...  recent  languages  such as Modula-II [Wirth 82] and  Ada  [DOD  80]
include  features specifically designed to help improve modularity.   However,
there is a very important point that is often missed.  When writing a  modular
program  to solve a problem, one first divides the program into  sub-problems,
then  solves the sub-problems and combines the solutions.  The ways  in  which
one  can divide up the original problem depend directly on the ways  in  which
one  can  glue solutions together.  Therefore, to increase  one's  ability  to
modularise  a problem conceptually, one must provide new kinds of glue in  the
programming language.

     "...  functional languages provide two new, very important kinds of  glue
[(higher  order  functions and lazy interpretation)].... This is  the  key  to
functional  programming's power - it allows greatly  improved  modularisation.
It is also the goal for which functional programmers must strive - smaller and
simpler and more general modules, glued together with the new glues...."

If  you only read one article about (purely) declarative languages, let it  be
this one.  You won't be disappointed.--

Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie
            Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
            Tel. [phone], [e-mail]

.pa
----------------------------------------------------------------------------
Date: 1 Jul 87 08:30:40 GMT
From: mcvax!ukc!dcl-cs![e-mail]  (Craig Wylie)
Organization: Department of Computing at Lancaster University, UK.
Subject: Software reuse  --  how do we reuse

The recent discussion on software reuse has highlighted several points that  I
would  like  to take further. The question of what it is has been  quite  well
covered  - basically it is what ever you want it to be regarding the reuse  of
any part of the the software design process.

I would like now to concentrate on one small area of reuse, reuse of  Software
Components,  and more particularly the recovery of a component from some  form
of catalogue. Many of the replies, both to me personally, and to the net  have
cited  'Libraries',  'Browsers',  and  'Intelligent  Systems'  as  methods  of
retrieving software.  I think that the analogy to lending libraries and online
bibliographic  retrieval  is  not  a  poor  one  but  that  it  does   require
considerably more thought.

Consider   an  example,   in  my  research  into  distribution  and   software
engineering  I  can go to a terminal, call up a bibliographic data  base,  and
search  on  terms  such as 'Reuse',  'Software  Engineering',  'Distribution',
'Concurrency'  etc.. The fact that these terms are very high level  makes  the
retrieval  process much easier, authors may well have included these terms  in
their  keywords  or  abstracts. The provision of a  synonyms  dictionary  will
enhance the system.

How can we provide similar power for components ? Obviously the keywords of  a
text  can  be  mimiced by the provision of keywords from the  authors  of  the
software component (or the authors of the design work or any other object that
might  be  reused),  however there is no point in retrieving  on  whether  the
program  contains a FOR loop. The automatic generation of keywords might  also
help,  if not definitive it might certainly act as an aid. Yet how can  we  do
this from languages such as Ada, it is far from proven that it is possible.

One of the great powers of bibliographic retrieval is the fact that any  paper
retrieved will have a list of references, so if the paper found isn't  exactly
applicable  then perhaps one of the referenced papers will be. How might  this
be mimiced?

If we are to continue to use the library analogy then we must derive a way for
talking  about programs that is accessible to all. Remember even Math  is  not
perfect  -  there can be more than one mathematical description  of  the  same
piece of software.

Fuzzy  logic  and browsers have their place, but rather than  citing  them  as
answers  we should be looking on them more as techniques once we know what  we
are dealing with.

Sorry about the rather bitty nature of this article  --  it has been a flow of
thought article, the views are entirely my own.

Craig
UUCP:     ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster,
DARPA:     craig%lancs.comp@ucl-cs          |      Department of Computing,
JANET:     [e-mail]           |      Bailrigg, Lancaster, UK.
Phone:     [phone] Ext. 4476         |      LA1 4YR




==============================================================================
Ada is a registered trademark, U.S. Government - Ada Joint Program Office. The
following are trademarks of Digital Equipment Corporation:  DEC, DECSYSTEM-20,
ULTRIX,  VAX,  VMS.   UNIX  is  a trademark of AT&T  Bell  Laboratories.   The
following are trademarks of Data General Corporation:  AOS, ROLM.  Verdix is a
trademark  of  Verdix Corporation.   TeleGen2 and TeleSoft are  trademarks  of
TeleSoft.

The Ada Software Repository Newsletter is Copyright 1986, 1987 Echelon, Inc.
All  Rights  Reserved.   Permission  to reprint,  wholly  or  partially,  is
automatically granted if source credit is given to Echelon.

                                                                 Echelon, Inc.
                                                       885 N. San Antonio Road
                                                       Los Altos, CA 94022 USA
                                                       Telephone: [phone]